< previous page page_62 next page >

Page 62
OOD's Role in Solution Development
Like analysis, design is usually a whirlwind process for many developers. Decisions about the detail architecture of the proposed system under development are made, for the most part, on an ad hoc basis. Typically, one individual arrives at such crucial decisions in an isolated setting, using his thought processes from a previous whirlwind design process to dictate the design process for the current domain. There is no sanity check (or organized feedback) from fellow developers, analysts (if any), and domain experts.
This isn't entirely the programmer's fault, however. Executives and managers, accustomed to the mainframe application development processes, have seldom established their IS and IT departments as they would other business groupsthat is, with no separation between a designer's role and a programmer's role, between the architect and the project manager. Generally, programmers are expected to double as designers (and sometimes analysts, architects, testers, documenters, and so on). For commercial and independent entrepreneurial developers, you will undoubtedly wear all these hats.
Solution development, and particularly system design, should be a very careful, methodical process. Because Visual Basic isn't quite object-oriented (OO), you have to be even more carefulwithout excessive worry, though. During the design phase, you want to pursue different pattern and coding strategies, based on the initial architecture exposed by the analysis phase. Architectural flaws discovered during design are far less costly than those discovered during the actual development phase. This is because during design, no coding is done (except for evolving a prototype as a sanity check for proof of concept). The artifacts of design are nonprogramming models, meaning that when logic flaws are discovered, those flaws can be easily corrected by modifying the corresponding document. When you skip or skim past design, the inevitable flaws you encounter during programming cost you the following:
Many extra hours of overtime
Unnecessarily increased levels of stress
Abnormally high levels of impatience among users and managers
Personnel turnover
Faulty programmer assumptions about the system, made in isolation
Excessive cost overruns
An unusually high increase in the risk of project failure
Programmers who have never tried implementing design in their software development repertoire criticize this phase as wasteful, time-consuming, and pointless. Such

 
< previous page page_62 next page >

If you like this book, buy it!